Typical file caching methods include a cache receiving a file from a file server, and storing the entire file. Later when a client desires the file, instead of serving the file from the file server, the file is served from the cache. Because the cache is typically a server that is closer to the client, or has higher bandwidth than the file server, the file is served to the client quickly from the cache.
The application of typical file caching methods to files that include streaming media data, for example Video on Demand (VoD) files, can lead to new problems. VoD systems generally either stream content through a set-top box, allowing viewing in real time, or download it to a device such as a computer, digital video recorder, personal video recorder or portable media player for viewing at any time. The data delivered by networks delivering such content can run to very large amounts, and caching can be particularly useful.
This can be understood with reference to FIG. 1, which is a schematic illustration of an exemplary architecture of a VoD system with deployed caches used to reduce the load on a central long-tail server. In the example, it can be supposed that the network uses Real-Time Streaming Protocol (RTSP) streaming, where the payload is transported over the User Datagram Protocol (UDP) in Real-Time Protocol (RTP) packets, but it will be appreciated that many other applications and protocols have a similar architecture and will have similar issues.
The architecture of FIG. 1 includes a network 100 having an origin server 101 and a number of caches 102-106. Clients 107-109 are configured to receive files and/or streaming data from the origin server 101 or the caches 102-106. The clients use RTSP to set up and control streams of RTP packets. This includes the negotiation of codecs, bitrates, ports etc for the resulting RTP stream. With RTSP the clients can start and stop the streaming, or fast forward or rewind the streamed media clip.
RTP packets are sent in sequence with a sequence number to tell the client the order of the packets. This infers a state into the protocol that the streaming server 101 needs to maintain and increment for each data packet it sends out. The sequence number is also used by the clients 107-109 to detect packet loss which is reported back to the streaming server using the Real-Time Transport Control Protocol (RTCP).
In order to reduce the load on the origin server 101 and to save bandwidth in the delivery network 100, some of the content is stored in caches 102-106 closer to the end users 107-109. It is desirable to push these caches as close to the end user as possible. However, this can give rise to problems in certain situations. For example, consider the situation in which there is mobility in the network so that the client can move around during a session (such as a mobile terminal moving between base stations). Suppose one of the clients 107 is receiving data from one of the caches 104. If the client 107 moves location so that it is now receiving data from another cache 105, dynamic parameters such as the session state (in this example, the RTP packet sequence number) need to be migrated into the new cache 105, which may or may not also include the relevant content, so that the session can continue in the new place without interruption.
Although caching solutions have been shown as an effective way of reducing the load on the transport network and have been proposed for video streaming, these solutions mainly focus on public Internet architectures and do not address the issues of mobility which is a vital part of 3GPP networks.
Long Term Evolution (LTE) is a communication network technology currently under development by the 3rd Generation Partnership Project (3GPP). LTE requires a new radio access technique termed Evolved Universal Terrestrial Radio Access Network (E-UTRAN), which is designed to improve network capacity, reduce latency in the network, and consequently improve the end-user's experience. System Architecture Evolution (SAE) is the core network architecture for LTE communication networks.
Referring to FIG. 2, the LTE/SAE architecture includes a Mobility Management Entity (MME) 24, which is responsible for control signalling. An SAE Gateway is responsible for the user data. The SAE Gateway consists of two different parts, namely a Serving Gateway (S-GW) 25 that routes user data packets, and a PDN Gateway (PDN-GW) 26 that provides connectivity between a user device and an external data network, such as a network 27 in which an operator is located to provide services such as IPTV 28 and IMS 29. These nodes are described in detail in 3GPP Technical Specification (TS) 23.401. All these nodes are interconnected by an IP network. Further nodes are the eNodeBs 22, 23, which act as base stations in the network. A Policy and Charging Rules Function, PCRF 30, detects the service flow and enforces charging policy. There are three major protocols and interfaces between these node types. These are S1-MME (between the eNodeBs 23, 23 and the MME 24), S1-U (between the eNodeBs 22, 23 and the S-GW 25), and X2 (between eNodeBs 22, 23). The corresponding protocols used in these interfaces are S1AP (S1 Application Protocol) and X2AP (X2 Application Protocol). All these protocols and interfaces are IP-based. In addition, the network may contain other nodes that are part of the above interface, for example a Home eNodeB Gateway (not shown in FIG. 2) between a Home eNodeB and rest of the nodes in the network. Currently, mobility is provided below the PDN-GW 26.
It is also helpful to consider the handover procedure in SAE/LTE networks when a mobile terminal 21 moves from a source eNodeB (eNB) 22 to a target eNB 23. According to 3GPP TS 36.300, the handover procedure is performed without involvement of the Evolved Packet Core (EPC), i.e. preparation messages are directly exchanged between the eNBs 22, 23. The release of the resources at the source side during the handover completion phase is triggered by the source eNB 22. The handover procedure is well defined in 3GPP TS 36.300 and is not reproduced here.
In the case of a System Architecture Evolution/Long Term Evolution (SAE/LTE)—network architecture, mobility of a user causes a change in attachment points into the network and introduces the following issues:                Session transfer due to mobility. If a cache is used below the mobility anchor points (i.e. the user moves from cache to cache), the complexity of having application states within the cache generates complexity during handoffs.        Interactions with Policy control. One of the main problems is that application nodes such as streaming servers need to interact with the Policy Charging Rule Function (PCRF) to control the usage of QoS. However, the PCRF is located above the anchor-point in the EPC-architecture and this causes a problem for a cache below the anchor-point.        Scalability. A problem is that a centralized generation of payload requires high-capacity nodes and is difficult to scale when more traffic needs to be generated.        